home *** CD-ROM | disk | FTP | other *** search
/ Amiga Tools 4 / Amiga Tools 4.iso / tools / developer-tools / assembler / d68k_jumplists / d68k.dok < prev    next >
Encoding:
Text File  |  1996-02-26  |  20.0 KB  |  543 lines
  1.  
  2.     D68k Version 2.0.8 von Denis Ahrens 1995 ShareWare
  3.  
  4.  
  5.     D68k ist ein SEHR schneller FILE-Disassembler für den MC68000
  6.     68010,68020,68030,68040,68060 FPU 68881,68882 und die PMMU 68851.
  7.  
  8.     Es werden Symbol-, Extern- und Reloc-Hunks unterstützt.
  9.  
  10.     Man kann mit D68k ALLES disassemblieren was aus Hunks besteht, also
  11.     auch Objektfiles und amiga.lib's. Desweiteren kann D68k auch
  12.     Bootblöcke und Kickstartfiles disassemblieren die als File
  13.     abgespeichert wurden.
  14.  
  15.     Die Funktionstabellen innerhalb von Librarys werden unterstützt.
  16.  
  17. ***************************************************************************
  18.  
  19.     SCHNELLSTART
  20.  
  21.     Er wird über das CLI gestartet mit Angabe des Files das
  22.     Ihr disassemblieren wollt.
  23.  
  24.     Man kann die Ausgabe mit Control-C jederzeit abbrechen.
  25.     Falls die Ausgabe im CLI-Fenster 'läuft', kann man mit einem
  26.     Tastendruck die Ausgabe anhalten und mit einem Druck auf die
  27.     Backspace-Taste fortsetzen.
  28.  
  29.     z.B.:
  30.  
  31.     1> D68k ram:Prgs/exep04
  32.  
  33.     würde so aussehen:
  34.  
  35. -------------------------------------------------------------------
  36. 01:D68k V1.xx MC68000-68040,MC68881/82,MC68851 Disassembler
  37. 02:Copyright DD.MM.95 by Denis Ahrens
  38. 03:
  39. 04:00000001 00288E20 00000040 00000004 00391828 00000000 00000000
  40. 05:
  41. 06:                 CODE       ;000 000004
  42. 07:
  43. 08:000000  4AFC                ILLEGAL
  44. 09:000002  4E71                NOP
  45. 10:
  46. 11:                ;Hunk-END
  47. -------------------------------------------------------------------
  48.     Die Zeilennummern am Anfang gehören natürlich NICHT dazu!
  49.  
  50.     In der vierten Zeile sind StatusInformationen die NUR für mich
  51.     sind (zum debuggen).
  52.  
  53.     Für Interessierte:
  54.  
  55.     1. Langwort:    Anzahl der Hunks (Nicht der Wert aus dem HUNK-HEADER!!)
  56.     2. Langwort:    SpeicherAdresse der Hunktabelle
  57.     3. Langwort:    Größe der Hunktabelle (Hunks * 64 Bytes)
  58.     4. Langwort:    Länge aller CODE, DATA und BBS Hunks zusammen
  59.     5. Langwort:    SpeicherAdresse der LabelTabellen
  60.     6. Langwort:    Anzahl der gefundenen Labels
  61.     7. Langwort:    Anzahl der sortierten Labels
  62.     
  63.     In der sechsten Zeile steht der HunkName (CODE) mit der Nr. (0)
  64.     und der Länge in Bytes (#4).
  65.  
  66.     In der achten und neunten Zeile steht (endlich) der PC
  67.     des Hunks, der MaschinenCode und am Ende das (der,die) Mnemonic.
  68.  
  69.     In der elften Zeile kommt dann die EndHunk-kennung.
  70.  
  71. ***************************************************************************
  72.  
  73.     DIE AUSGABE
  74.  
  75.     Bei RELOCxx-Hunks (Reloc32,16,08) wird die Anzahl der zu
  76.     korrigierenden Adressen angezeigt. Das ist praktisch zum Optimieren
  77.     eigener Programme. Wenn man mit relativer Adressierung arbeitet,
  78.     erkennt man so schnell, ob man eine Zeile ohne relativ-code
  79.     geschrieben hat.
  80.  
  81.     Bei SYMBOL-Hunks die Anzahl der Symbole.
  82.     Bei UNIT- und NAME-Hunks werden die Namen angezeigt.
  83.     Bei EXTERN-Hunks werden die Inhalte der Typen <$80 angezeigt.
  84.  
  85.     Wenn D68k einen Bootblock erkennt wird anstelle des Hunk-Namens das
  86.     Wort BOOTBLOCK ausgegeben. Die CODE-Größe ist auf 1024 Bytes minus
  87.     3 Langwörter beschränkt. (FileSystem-Kennung,Checksumme und
  88.     Rootblock)
  89.  
  90.     Um den Code mit A68k zu Re-Assemblieren muß man am Ende des
  91.     'Textes' ein " END" anfügen.
  92.     Eventuell muß man den Code noch an seinen persönlichen
  93.     Assembler anpassen (Ich hoffe nicht).
  94.  
  95. ***************************************************************************
  96.  
  97.     EINIGE ERKLÄRUNGEN
  98.  
  99.     Wenn D68k einen Befehl NICHT erkennen kann, (und er kennt ALLE
  100.     Befehle) oder ein Befehl eine NICHT zulässige Adressierungsart hat,
  101.     wird er NICHT angezeigt (z.B. JMP D0 oder JSR (A0)+ ). Stattdessen
  102.     wird ein Word als Hexzahl ausgegeben.
  103.  
  104.     Bei Befehlen mit Byte-Konstanten, bei denen das high-order-byte
  105.     NICHT NULL ist, wird auch das als illegaler Befehl interpretiert.
  106.     Da aber manche Assembler/Compiler das Byte per EXT.W zum Wort
  107.     erweitern (was FALSCH ist), wird bei negativen Bytewerten der Wert
  108.     $ff im high-order-byte eingetragen. Dies wird von D68k
  109.     berücksichtigt. Das high-order-byte muss also $00 oder $ff sein.
  110.  
  111. ***************************************************************************
  112.  
  113.     Die NORMALE Methode (TRACE ist NICHT eingeschaltet)
  114.  
  115.     Der Nachteil liegt darin das bei der 'normalen' Methode nach einem
  116.     RTS zum Beispiel der Text 'topaz.font',0 auch disassembliert würde.
  117.     Dadurch entstehen wirre Befehle, weil sich Datas und Befehle oft
  118.     nicht unterscheiden lassen. Unglücklicherweise liegen die kleinen
  119.     Buchstaben als ASCII-Code bei $60-70, und genau dort sind die
  120.     ganzen BRANCH- und MOVEQ-Befehle. Durch die BRANCH Befehle werden
  121.     Fehl-Labels erzeugt und dadurch wird die Ausgabe undurchschaubar.
  122.  
  123.     In manchen Disassemblern werden NICHT angesprunge Befehle im Code-
  124.     Hunk als Data-Zeilen angezeigt. Da dies nicht immer klappt, geht
  125.     das NICHT mit D68k. Bei der 'normalen' Methode werden im CODE-Hunk
  126.     NUR Datas angezeigt wenn KEIN Befehl erkannt wird. Wenn ein
  127.     Programm nur MC68000 Befehle enthält und Daten oder Texte von D68k
  128.     als MC68010 Befehle (oder höher) erkannt werden, klappt das
  129.     natürlich nicht. Aber meiner Meinung nach haben Daten in Code-Hunks
  130.     nichts zu suchen.
  131.  
  132.     Falls D68k Librarynamen im Code-Hunk erkennt, werden diese
  133.     umgangen. In PASS1 wird die Länge des Library-Textes übersprungen
  134.     und in PASS2 wird auf Daten-Ausgabe umgeschaltet. Folgende
  135.     Libraries werden unterstützt falls sie an einer geraden Adresse
  136.     beginnen:
  137.  
  138.     68040.library        dos.library
  139.     icon.library        intuition.library
  140.     expansion.library    utility.library
  141.     gadtools.library    graphics.library
  142.     iffparse.library    workbench.library
  143.     asl.library        locale.library
  144.     bullet.library        commodities.library
  145.     diskfont.library    exec.library
  146.     .library        .device
  147.  
  148. ***************************************************************************
  149.  
  150.     DIE TRACE-Methode !!!!!!!!!!!!!!!!!!!!!!!!
  151.  
  152.     Der Unterschied zur normalen Methode ist der, das D68k im ersten
  153.     PASS nicht einfach geradeaus durchdisassembliert, sondern bei einem
  154.     UNBEDINGTEM Sprung (BRA.x, JMP.x, RTS oder RTx) anhält und sich
  155.     eine neue Adresse holt, die vorher vermerkt wurde, und dort weiter
  156.     disassembliert u.s.w. Alle so abgearbeiteten Adressen werden als
  157.     Befehle markiert.
  158.  
  159.     Falls ein Programm aber eine Adresse mit dem Befehl LEA in das
  160.     Adressregister A2 'ladet', und dann per JSR A2 verzweigt kann die
  161.     TRACE-Methode das nicht nachvollziehen. Die Befehle werden dann
  162.     nicht markiert und werden deshalb im zweiten PASS als Datas
  163.     ausgegeben weil D68k diese NICHT als CODE vermerkt hat. Um diesen
  164.     Umstand auszugleichen besteht die Möglichkeit, ein Text-File
  165.     anzulegen das eine Tabelle enthält, in der die Adresse(n) steht,
  166.     die z.B. mit dem LEA-Befehl nach A2 geladen wurde. D68k kann dann per
  167.     Option das File einlesen, und die Adresse in die interne
  168.     SprungTabelle eintragen, um auch diese, vorher nicht erkannten
  169.     Befehls-abschnitte disassemblieren zu können.
  170.  
  171.     BEISPIEL:
  172.  
  173.     Man disassembliert den LIST Befehl folgendermaßen:
  174.  
  175.     1> D68K "c:Loadwb" TO "ram:loadwb.asm" TRACE RLO
  176.  
  177.     dann betrachet man das Ergebnis mit einem Editor und sucht
  178.     Data-Stellen die nach Befehlen aussehen. (Z.B. kurz vor dem
  179.     nächsten Label steht der Wert $4E75, der dem Befehl RTS entspricht)
  180.  
  181.     Im T: Verzeichnis sollte jetzt ein File mit dem Namen
  182.     'JumpList.Loadwb' abgespeichert worden sein. Ladet dieses File mit
  183.     einem zweiten Editor ein. Die Adressen die Ihr im letzten Schritt
  184.     gefunden habt könnt Ihr nun am ENDE dieses Files eintragen.
  185.  
  186.     D68k interessieren nur zwei Hex-Zahlen pro Zeile die mit einem
  187.     Komma getrennt sind und mit einem Dollarzeichen ($) beginnen. Das
  188.     HexZahlenpaar muß (noch) am Anfang der Zeile stehen. Mann kann auch
  189.     ein Semikolon benutzen um Werte zu Testzwecken auszuklammern.
  190.  
  191.     Als erste Zahl muß die HunkNummer, und als zweite Zahl die Adresse
  192.     eingetragen werden. Die Hunknummer steht immer am Anfang des Hunks
  193.     (an Adresse Null) im Dezimalformat. Ihr müsst also die Zahl noch
  194.     umwandeln.
  195. ________________________________________________
  196.  
  197.     ;
  198.     ; D68k V1.93 JumpList for 'Loadwb' V38.9
  199.     ;
  200.  
  201.     $00015455,$00000470    ;Die File-Identifikation und File-Größe
  202.  
  203.     $00,$00035E    ;hier kann man Bemerkungen eintragen
  204.     $00,$0003B4
  205. ________________________________________________
  206.     
  207.     Die Versionsnummer solltet Ihr auch eintragen. Dann kommt Ihr nicht
  208.     durcheinandner, wenn Ihr vom dem Programm eine neue Version
  209.     erhaltet. Wenn D68k eure JumpList nicht akzeptiert, dann stimmt die
  210.     Fileidentifikation in dem JumpList-File NICHT mit dem eingeladenen
  211.     File überein.
  212.  
  213.     Speichert das File unter dem Namen 'JumpList.Loadwb' in diesem
  214.     Verzeichnis ab:
  215.  
  216. !!!            D68k_JumpLists/
  217.  
  218.     Jetzt gebt folgende Zeile ein:
  219.     (Editor im hintergrund laufen lassen)
  220.  
  221.     1> D68k "C:Loadwb" to "ram:Loadwb.asm" TRACE RLO JUMPLIST
  222.  
  223.     Nun könnt Ihr wieder zum Editor umschalten und das File
  224.     "Loadwb.asm" nocheinmal einladen. Die vorher nicht erkannten
  225.     Befehle sind nun ordentlich disassembliert. Falls noch weitere
  226.     Befehls-abschnitte NICHT disassembliert wurden, könnt Ihr weitere
  227.     Adressen  in  dem  JumpList-File eintragen und die letzten Schritte
  228.     wiederholen.
  229.  
  230.     Meistens genügt es, wenn man eine Adresse einträgt, denn hierdurch
  231.     werden meist weitere Adressen vermerkt, wodurch ev. eine Ketten-
  232.     reaktion entsteht.
  233.  
  234. ------------------------
  235.  
  236.     Wer es eilig hat, kann die fertigen JumpListen aus dem Archiv
  237.     in das D68k_JumpLists/ Verzeichnis kopieren. Wenn Ihr die gleichen
  238.     Versionen der dortigen Programme 'besitzt', könnt Ihr diese gleich
  239.     benutzen, da ich die Adressen schon eingetragen habe.
  240.  
  241.     Nochmal der vollständige Pfad der JumpListen:
  242.  
  243.     "D68K_JumpLists/JumpList.Loadwb"
  244.  
  245. !!    Wobei "D68k_JumpLists/" in der "homedirectory" von D68k sein muss!.
  246.  
  247. ------------------------
  248.  
  249.     Es  gibt  zwei Methoden von NICHT erkannten Sprung-Adressen, einmal
  250.     mit Label und einmal ohne Label.
  251.  
  252.     1.
  253.     Falls die von euch als Befehle identifizierte Routine ein Label
  254.     hat, kann man das File "Loadwb.asm" nach diesem Label absuchen (mit
  255.     der Editor-Suchroutine) und den weiteren gebrauch der Adresse
  256.     verfolgen. So stellt man sicher das es sich wirklich um eine
  257.     Befehls-Routine handelt.
  258.  
  259.     2.
  260.     Wenn der Routine kein Label vorangestellt ist, dann solltet Ihr das
  261.     File "Loadwb.asm" nach JSR's und JMP's durchsuchen. Wenn ein
  262.     solcher Befehl relativ springt (z.B. JSR (A0) oder JMP 0(PC,D0.l)
  263.     dann solltet Ihr verfolgen wie das Ziel des Sprunges errechnet
  264.     wird. Falls kein Sprung zu dieser Adresse zu finden ist, handelt es
  265.     sich vielleicht um eine 'tote' Routine die NICHT angesprungen wird.
  266.     Wenn Ihr euch ABSOLUT sicher seid, könnt Ihr diese Routine
  267.     entfernen.
  268.  
  269.     DIE TRACE-LOGIC (1)
  270.  
  271.     Um die TRACE-Methode noch sicherer zu machen, werden von D68k
  272.     auch SprungTabellen erkannt die per JMP L000012(PC,D0.W) springen.
  273.     Diese  Tabellen  sehen so aus, wenn sie von D68k als solche erkannt
  274.     wurden:
  275.  
  276.      ...CMPI.W    #$0014,D1            ;Anzahl der Einträge
  277.     BGE.W    L000016                ;Bei Überlauf verzweigen...
  278.     ADD.W    D1,D1                ;Verdoppelung (wegen Wortgröße)
  279.     MOVE.W    L00000F(PC,D1.W),D1        ;relative Distanz holen
  280.     JMP    L000010(PC,D1.W)        ;und springen
  281. L00000F:
  282.     dc.w    L000011-L000010            ;hier stehen die Differenzen
  283. L000010:                    ;vom DIESEM Label aus
  284.     dc.w    L000011-L000010            ;bis zum Sprungziel.
  285.     dc.w    L000012-L000010
  286.     dc.w    L000013-L000010
  287.     dc.w    L000014-L000010
  288.     dc.w    L000015-L000010
  289. u.s.w....
  290.  
  291.     Da diese Sprungtabellen sehr verschieden programmiert werden,
  292.     ist es sehr schwierig alle Möglichkeiten abzudeken.
  293.  
  294.     Da die TRACE-Methode sehr gut ist, wird die DATALOGIC übergangen.
  295.     Auch die RTSLOGIC sollte ausgeschaltet werden. D68k sucht auch
  296.     nicht mehr nach Libraries, wie bei der normalen Methode.
  297.  
  298. ***************************************************************************
  299.  
  300.     DIE OPTIONEN VON D68k:
  301.  
  302.     ?    Listet alle Optionen auf
  303.  
  304.     FILE:    Als erstes wird natürlich der Filename des zu
  305.         disassemblierenden Files angegeben.
  306.  
  307.     TO/K:    Mit dieser Option kann man die Ausgabe in ein File umlenken
  308.         Das Intro und die INFO's werden NICHT mit ausgegeben.
  309.         Dafür wird zusätzlich der VERSIONS-String ausgegeben, der
  310.         Name des Files und die Länge in Bytes.
  311.  
  312.     NOPC/S:    Dies MUSS angegeben werden wenn man re-assemblieren möchte.
  313.         Hierdurch werden der PC und die HEX-Codes weggelassen.
  314.         Das spart eine Menge an Zeit, und das ev. erstellte File
  315.         ist wesentlich kürzer.
  316.  
  317.     INFO/S:    Es werden ein paar Informationen zu dem File angezeigt
  318.         (FileSize, HunkAnzahl, Labels ...).
  319.         Die Informationen erscheinen nur im Ausgabefenster, das ist
  320.         nützlich wenn man die Ausgabe in ein File umlenkt und
  321.         trotzdem ein paar Informationen sehen will.
  322.  
  323.     HUNKLAB/S:
  324.         Es werden die Label-Adressen von Symbol-Hunks aufgelistet.
  325.         Die Offets von EXT-Hunks werden angezeigt.
  326.         (Aber nur die des Typs < $80)
  327.  
  328.         PROBIER DAS zum testen der Option: D68k LIB:amiga.lib hunklab
  329.         (Das ist praktisch um die neuen Offsets aus einer NEUEN
  330.         amiga.lib zu ziehen, falls man sie hat.)
  331.  
  332.     NC=NOCODE/S
  333.         Die Ausgabe der Befehle wird unterdrückt. Das ist praktisch
  334.         wenn man NUR die DATA-Ausgabe sehen will, dann braucht man
  335.         nicht mehr ewig-lange CODE-Zeilen scrollen lassen.
  336.  
  337.     ND=NODATA/S
  338.         Die Ausgabe des Inhaltes aller Daten-Hunks wird unterdrückt.
  339.  
  340.     NB=NOBSS/S
  341.         Die Ausgabe aller BSS-Hunk Anweisungen wird unterdrückt.
  342.  
  343.     68020/S    Es werden auch Befehle (und Adressierungsarten) disassembliert
  344.         die einen MC68020 oder höher benötigen. Durch WEGLASSEN
  345.         dieser Option spart man eine Menge an Zeit, und es wird auch
  346.         nicht mehr soviel "fehlinterpretiert", denn meistens
  347.         sind es ja sowieso nur 68000'er Programme.
  348.  
  349.     HEXDATA/S
  350.         Mit dieser Option werden die Daten zusätzlich zu ASCII-
  351.         format im Hexformat angezeigt.
  352.  
  353. ------------------------------------
  354.  
  355.         Die TRACE-Methode und ihre Optionen
  356.  
  357.     TRACE/S
  358.         Mit dieser Option wird eine alternative Methode benutzt
  359.         um Labels und Datas in Code-Hunks zu erkennen. Es werden
  360.         alle Sprungmarken notiert bis ein UNBEDINGTER Sprung kommt.
  361.         Dann wird eine von den notierten Sprungmarken geholt und an
  362.         dieser Stelle wird weiter disassembliert.
  363.         Vorteil : Es wird NIE in Datas disassembliert.
  364.         Nachteil: Falls per JSR (A0) gesprungen wird, kann diese Adresse
  365.               nicht notiert werden und demzufolge fällt dieser
  366.               Programmabschnitt (und dadurch ev. weitere) weg.
  367.  
  368.     JL=JUMPLIST/S
  369.         Mit dieser Option (nur zusammen mit TRACE) kann man bestimmen
  370.         das D68k sich 'notierte' Adressen aus einem File zieht. Dieses
  371.         File MUSS im Verzeichnis D68k_JumpLists zu finden sein.
  372.         Der Name fängt mit "JumpList." an und endet mit dem Filenamen
  373.         den man zum disassemblieren angegeben hat.
  374.         In diesem Text-File können von Ihnen eingetragene Adressen
  375.         stehen, die D68k sich als abzuarbeitende Sprungmarken merkt.
  376.         Dieses gleicht den Nachteil der TRACE-Methode vollständig aus.
  377.  
  378. ------------------------------------
  379.  
  380.         Die folgenden Routinen sind nur für die 'normale' Methode
  381.         sinnvoll.
  382.  
  383.     RLO=RTSLOGICOFF/S:
  384.         Wenn nach einem RTS Befehl kein Label folgt ist es ziemlich
  385.         unwahrscheinlich das Code folgt. Deshalb werden automatisch
  386.         nachfolgende Programmdaten als Hex-Datas ausgegeben.
  387.         Mit dieser Option kann diese automatische Unterdrückung der
  388.         Befehle hinter einem RTS Befehl abgeschaltet werden.
  389.         (Das gleiche gilt für die Befehle: BRA, JMP, RTD, RTE, RTM, RTR)
  390.         (Sollte bei der TRACE-Methode benutzt werden)
  391.  
  392.     DLO=DATALOGICOFF/S
  393.         Bei D68k werden NICHT erkannte Hex-Codes als Datas ausgegeben.
  394.         Weil der PC an diesen Hex-Codes sowieso nicht vorbeikommt,
  395.         können alle nachfolgenden Hex-Codes bis zum nächsten Label
  396.         auch als Datas ausgegeben werden. Mit dieser Option kann man
  397.         diese Logik abschalten und nur WIRKLICH nicht erkannte Hex-Codes
  398.         werden als Datas angezeigt.
  399.         (Schaltet die 'RTSLOGIC' auch mit aus)
  400.  
  401.     OLO=ORILOGIC/S
  402.         Bei ORI.x Befehlen die aus zwei Wörtern bestehen und ein
  403.         Label zwischen den beiden Wörtern ist, wird ein Wort als
  404.         Data ausgegeben und die Befehlsausgabe mit dem Label
  405.         fortgesetzt. (Wenn nach einem RTS ein 'LeerWort' folgt um
  406.         die Routine durch vier teilbar zu machen, denkt D68k das das
  407.         ein ORI-Befehl ist. Mit dieser Option kann man diese Befehle
  408.         aussschalten.)
  409.  
  410. ------------------------------------
  411.  
  412.         Die folgende Routine ist nur zum Debuggen von D68k.
  413.  
  414.     NL=NEXTLABEL/S
  415.         Mit dieser Option wird die Längendistanz bis zum nächsten Label
  416.         oder Symbol angezeigt (direkt vor dem PC). Wenn die NOPC-
  417.         Option benutzt wird, fällt diese automatisch weg.
  418.         (Ist eigentlich mehr für MICH zum debuggen).
  419.  
  420. *******************************************************************************
  421.  
  422.     WARUM ICH D68K GESCHRIEBEN HABE:
  423.  
  424.     Ich bin neugierig und der DisAsm 1.05 war mir
  425.  
  426.     1. zu langsam
  427.     und außerdem
  428.     2. benutzt er tausende von SPACE's (ich nehm' TAB's)
  429.     3. er spinnt bei OS V36 und höher
  430.     4. zeigt zuwenig Nebeninformationen
  431.     5. ist er nicht anpassbar (an meine Wünsche)
  432.     6. erkennt keine 68020.. Befehle
  433.     7. Kreuzberger Nächte sind lang.
  434.  
  435.     Die anderen Disassembler sind entweder zu langsam, haben keine
  436.     vernünftige Ausgabe oder kennen keine 68020.. Befehle.
  437.  
  438. *******************************************************************************
  439.  
  440.     WAS VERBRAUCHT D68K AN SPEICHER?
  441.  
  442.     1. Die eigene Länge
  443.     2. Die Größe des zu disassemblierenden Files
  444.     3. 256kB für die Labels
  445.     4. Pro Hunk werden einmal 64 Byte (genauer Wert in der Status-Zeile
  446.        3.LW) und nochmal 1024 Byte belegt (Nur bei Code-Hunks!).
  447.     5. Falls die Trace-Option eingeschaltet ist nochmal ein sechszehntel
  448.        der Code-Hunklängen. (Pro Wort ein Bit)
  449.     6. Falls die Trace-Option eingeschaltet ist 32kB für die Sprungmarken.
  450.  
  451.     7. Falls eine JumpList eingeladen wird, wird dieser Speicher nur
  452.        kurzzeitig belegt.
  453.  
  454.     8. Falls die Ausgabe per Option umgelenkt wurde wird ein Buffer von
  455.        64KB belegt (SetVBuf()). Dieses aber nur unter OS V39.
  456.  
  457. *******************************************************************************
  458.  
  459.     FEHLER:
  460.  
  461.     Zeigt aus optischen Gründen keine Labels an ungeraden Adressen
  462.     im CODE-Hunk an (da dürften aber auch gar keine sein).
  463.     (teilweise behoben: Wenn Daten angezeigt werden, erscheinen auch
  464.     Labels an ungeraden Stellen)
  465.  
  466.     Erkennt bisher nur Librarys wenn sie mit ".library" enden, wobei
  467.     es case-sensitive ist.
  468.  
  469. *******************************************************************************
  470.  
  471.     D68k ist vollständig in MC68000 Assembler geschrieben, und
  472.     läuft nur mit OS V2.x oder höher ( dos.library >= 37.
  473.     Der Rechner selbst spielt keine Rolle. Schnell muß der
  474.     Rechner NICHT sein.
  475.  
  476.     D68k ist auf (m)einem Amiga 1000 mit MC68010 2MB FRAM und 130MB
  477.     Seagate AT-BUS HD unter OS2.1 geschrieben worden.
  478.     D68k wurde mit A68k 2.71 assembliert und mit bLink gelinkt.
  479.     Das File-Datum von D68k muß mit dem im Programm übereinstimmen.
  480.     Der Source-Code umfasst ca. 13900 Zeilen (260kB).
  481.  
  482.     Es ist inzwischen ein A4000/030 50mhz mit zwei WD Caviar 700MB und
  483.     540MB, 16MB FRAM und einem 15" VGA Monitor.
  484.  
  485.     Das Programm D68k ist SHAREWARE.            (SWC:02)
  486.     Aber es soll jeder selber entscheiden, was Ihm D68k Wert ist!
  487.     Für Leute die sich nicht entscheiden können, schlage ich DM 30,- vor.
  488.  
  489.     D68k sollte (darf) nicht benutzt werden um Schutz-Techniken von
  490.     Programmen zu entfernen.
  491.     Das Programm D68k darf nur ZUSAMMEN mit der Anleitung verbreitet
  492.     werden. Die kommerzielle Nutzung und/oder Verbreitung des
  493.     Programmes bedarf meiner SCHRIFTLICHEN Erlaubnis. Auch die
  494.     Verbreitung in KOMMERZIELLEN (gebührenpflichtigen)
  495.     PD-MailBox-Systemen ist NICHT gestattet.
  496.  
  497.     Die Veröffentlichung auf der Meeting Pearls CD-Reihe ist erlaubt,
  498.     solange die Preise der neuen CD der ersten Meeting Pearls
  499.     CD entsprechen UND es vermerkt wird, dass die Shareware-Gebühr
  500.     mit dem Kauf einer Meeting Pearls CD NICHT bezahlt ist !!!
  501.  
  502.     Es verstößt gegen das Urheberrecht, wenn Disassemblerlistings oder
  503.     modifizierte Versionen von fremden Programmen veröffentlicht werden,
  504.     oder wenn Programmteile aus fremden Programmen in eigenen Programmen
  505.     verwendet werden. Ausnahmen müssen vom Autor des fremden Programms
  506.     ausdrücklich genehmigt worden sein!
  507.  
  508.     Der Schreiber des Programms übernimmt keine Haftung für materielle
  509.     oder geistige Schäden, die durch D68k entstanden sind - entstehen
  510.     werden. Das Benutzen des Programmes geschieht auf EIGENE Gefahr!.
  511.  
  512.  
  513.     Die BinarySearch-Routine ist gespendet von Arno Eigenwillig.
  514.  
  515.  
  516.     Meine Adresse:
  517.  
  518.     IRC:    D68k oder DenisX
  519.  
  520.     EMail:    snipgija@sp.zrz.tu-berlin.de
  521.  
  522.     SMail:    Denis Ahrens
  523.         Alte Jakobstr.16
  524.         10969 Berlin
  525.         Deutschland
  526.  
  527.     Tel:    +49-030-614-6127
  528.     MODEM:    USR Courier V.34+
  529.  
  530.     BLZ:    100 100 10
  531.     KontoNr:2062 61-101
  532.  
  533. -----BEGIN PGP PUBLIC KEY BLOCK-----
  534. Version: 2.6.2i
  535.  
  536. mQCoAi6ktFsAAAEE0gMsJZudB6G7co+Va0MQtLMVcDHOHARCHo7qriFsZ8hvLZef
  537. io7iAlNfdTp9EE9albXYqOIaa4r8dGAzhj3KM/Mvs1qAiiS4vkQfP9lrIMs6Y2/8
  538. yFqcG6gPsWe2EugmprCdEhAhZfuntKCaR8rtmEQJlmKDHdF4+UYGThSBI+ffk1b9
  539. 2fzS25/RJO2FWS89KAY13JT8JcP/Ii9RAAUTtBtEZW5pcyBBaHJlbnMgSVJDLU5J
  540. Q0s6IEQ2OEs=
  541. =PVTS
  542. -----END PGP PUBLIC KEY BLOCK-----
  543.